This present invention relates generally to the field of security permissions for applications, and more specifically, to generating security permissions for applications in an enterprise environment.
Java 2 Security is a fine-grained, policy-based access control mechanism that is intended to increase overall system integrity by guarding access to protected system resources. (Java and ail Java-based trademarks and logo are trademarks or registered trademarks of Oracle and/or its affiliates.)
A typical scenario that occurs when Java 2 Security is enabled is that applications will stop working due to security access exceptions. The system administrator has to set up a coherent security policy, and this requires experience and security expertise on the part of the system administrator. An alternative option is to allow users to handle the policy management, which may result in mistakes being made due to their lack of expertise in defining security policies.
In many cases, in order to get applications working quickly, applications are given the permission “AllPermission” which is all encompassing and essentially negates the value that Java 2 Security is intended to provide.
Once the application is working, the tendency is not to go back to define proper security settings. System users may have a misplaced sense of security and assume that they have security protection as they know that Java 2 Security is enabled on the server.
Users that attempt to define the correct policy for their files may encounter difficulties. Often it is recommended that the application code be executed and that each time a security exception is hit, the security exception is analysed. Examples of options that may be taken when a security exception is encountered include: put the code in a “doPrivileged” block if the code is trusted (a drawback to this option is that this will open security holes); add the exception to the security policy file; and recode the application if the application should not actually be using that code.
The decision of which option to take requires a good understanding of security and of the application code. Once users have decided which option to take, they rerun the application again and potentially hit the next security exception and repeat the process until the application runs cleanly. Even once the application has run cleanly there is no guarantee that all the code paths which might generate a security exception will have been exercised, so it may just be a matter of time before the user hits the next one.
Adding to the difficulty of defining a security policy is that enterprise applications are often made up of multiple components. In the case of Java Enterprise Edition (EE) Enterprise Archive (EAR) files, the components might include, for example, Java Archive (JAR) files or Web application Archive (WAR) files contained in a hierarchy. Similarly, for OSGi Enterprise Bundle Archive (EBA) enterprise applications, the components might consist of different bundles in a hierarchy. (OSGi is a trademark or a registered trademark of the OSGi Alliance in the United States, other countries, or both.) Java 2 Security can be defined hierarchically to allow policies to be fine-tuned to the separate components. To add to the complication, the way these are defined for the different enterprise applications is different as well. In addition, the format of these policies is extremely sensitive to incorrect formatting, and they are of slightly different formats for each type of enterprise application.